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A METHOD AND SYSTEM FOR REMOTELY AUTHENTICATING 
IDENTIFICATION DEVICES 
RELATED APPLICATIONS 

This application is a continuation in part of PCT/IL01/00758 filed on 14 August 2001 
5 (14.08.01) and USSN 09/853,017 filed on 10 May 2001 (10.05.01), and claims the benefit 
under 119 (e) of 60/278,065 filed on 22 March 2001 (22.03.01), USSN 60/278,010 filed on 
22 March 2001 (22.03.01) and USSN 60/277,996 filed on 22 March 2001 (22.03.01), the 
disclosures of which are incorporated herein by reference. 
Field of the Invention 

10 The present invention relates to authentication methods. In one aspect thereof, the 

invention relates to a method and system for authenticating an identification devices, such as 
a self-powered card (hereinafter referred to as SPC). 
Background of the Invention 

In order to facilitate the reading of the description to follow, a number of terms and 

1 5 acronyms, which are well known in the art are defined below. These definitions are not to be 
taken as limiting and are provided as examples for facilitation of understanding of the 
disclosure. A complete and exact definition may be found in various books and other 
publications in the relevant fields. 

Authentication is the process of verifying an object or message to ensure that the object or 
20 message are what they purport to be and/or were not tampered with. For example, 
authenticating an e-mail message can check that it was signed using a method that can only 
be performed by the supposed sender. 

Encryption is the conversion of data into a form that cannot be easily understood by 
unauthorized people. Decryption is the process of converting encrypted data back into a 
25 form, in which it can be (at least partly) understood. Un-encrypted data is usually called 
Plain-text while encrypted data is referred to as Cipher-text. In some encryption methods, the 
encryption and decryption are subject to a Key, used for conversion between one form and 
the other. 

Cryptography is the art of protecting information by encrypting it into, an unreadable format 
30 (i.e. cipher-text). In some implementations, only those who possess a secret key can decrypt 
the message into plain text. 
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As the Internet and other forms of electronic communication become more prevalent, 
electronic security is becoming increasingly important Cryptography is therefore used to 
protect data such as e-mail messages, credit card information, and so forth. 
Symmetric-key cryptography is an encryption method in which the sender and receiver of 
5 a message share a single, common key, which is used to encrypt and decrypt the message. 
Symmetric-key systems are simpler and faster, but their main drawback is that the two 
parties must somehow exchange the key in a secure way. Also, the receiver can pretend (to 
third parties) to be the sender, using the key. 

The most popular symmetric-key system is the DES (Data Encryption Standard), also 
1 0 described below. 

Asymmetric-key cryptography is a cryptographic system that uses two keys - one key for 
encryption and another key for decryption. 

Public-key cryptography is an asymmetric-key cryptography. According to this method, 
one key is known to a plurality of persons (and hence called Public-key), while the other key 

15 is known only to one person (and hence called Private-key). 

An important feature of the public key system is that the public and private keys are related 
in such a way that once the public-key is used to encrypt a message, only the corresponding 
private key can be used to decrypt it. Theoretically, it is impossible to deduce the private-key 
from the corresponding public-key. 

20 According to one implementation, when a sender wants to send a secure message to a 
recipient, he uses the recipient's public-key to encrypt the message, and the recipient uses his 
corresponding private-key to decrypt it. That way, the recipient of a data can be sure that the 
data comes from a purported sender (if the key was not stolen. . .), and the sender can be sure 
that the data reaches the right destination. 

25 Pseudo-random numbers are numbers having properties similar to those of random 
numbers, for example, certain distribution properties and lack of (easily discernible) 
relationship between consecutive numbers. True, unbiased, random numbers are difficult if 
not impossible to generate. Pseudo-random numbers can be generated using computing 
machinery means, software and hardware. These means are usually called "Random-number 

30 generators", or RNG. Both linear and non-linear RNGs are known, with linear RNGs having 
a greater predictability problem. 

DES (Data Encryption Standard) is a NIST-standard secret key cryptography method that 
uses a 56-bit key. DES is based on an IBM algorithm that was further developed by the U.S. 
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National Security Agency. It uses the block cipher method, which breaks the text into 64-bit 
blocks before encrypting them. There are several DBS encryption modes. The most popular 
mode exclusive ORs each plain text block with the previous encrypted block. 
DES3 (also called Triple DES) is an enhancement to DES that provides more security than 
5 standard DES, which uses only one 56-bit key. DES3 may be also be used for generating 
random numbers. 

A Hash function is a transformation that converts a number (or other data representation) 
from a large space to a (typically) smaller space, typically with an even distribution. In a 
typical implementation, a hash function is used to convert a large string of fixed or varying 

10 length into a short value of a fixed size, which is called the Hash value of the string. One 
property of many Hash functions is that they are truly unreversible in that the original 
number cannot be reconstructed from the Hash value. This can be useful for protecting 
against untrustworthy employees. Merely encrypting the data may not be enough if the 
employee can steal the keys for decryption. It is often desirable that the computational effort 

15 be relatively moderate. Providing an even distribution may be useful in reducing the number 
of collisions (e.g., different inputs with same has value. Examples of well-known Hash 
functions are MD2 and MD5 . - 

E-wallet is a recent effort to provide the electronic equivalent of a wallet (or better than 
equivalent) for e-commerce transactions and/or for physical transactions. Many 

20 , implementations are known. One implementation is that a digital wallet (e-wallet) holds 
digital money that is purchased similar to travelers-checks, a prepaid account, or it can 
contain credit card information. The wallet may reside, for example, in a user's machine 
(including an electronic device/card) or on the servers of a Web payment service. When 
stored in a user's machine, the wallet may use a digital certificate for identifying a 

25 cardholder. 

SSL (Secure Sockets Layer) is a commonly used protocol for managing the security of a 
message transmission on the Internet. SSL uses a program layer located between the 
Internet's Hypertext Transfer Protocol (HTTP) and Transport Control Protocol (TCP) layers. 
SSL is included as part of both the Microsoft and Netscape browsers and many Web server 
30 products. The "sockets" part of the term refers to the sockets method of passing data back 
and forth between a client and a server program in a network or between program layers in 
the same computer. SSL uses the public-and-private key encryption system provided by 
RSA, which also includes the use of a digital certificate. 
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CRC (Cyclic redundancy checking) is a method of checking for errors in data that has been 
transmitted on a communications link. A sending device applies a 16- or 32-bit polynomial 
to a block of data that is to be transmitted and appends the resulting cyclic redundancy code 
(CRC) to the block. A receiver applies the same polynomial to the data and compares its 
5 resulting CRC with the result appended by the sender. If they agree, the data has probably 
been received successfully. If not, the sender can be notified to resend the block of data. 
One Time Code is a method by which whenever an authentication trial is initiated, a unique 
code, single use (or possibly small number of uses), is provided for authentication. 
BACKGROUND 

10 The Internet, and the World Wide Web (WWW) in particular, has grown in 

popularity in recent years. In addition to news and information, merchants and consumers 
alike have come to view the web as a virtually unlimited range for conducting business, in 
the form of sales of products, services, and information. Nevertheless, many computer users 
axe still somewhat leery of conducting sales transactions over the Web especially because 

15 credit cards are involved, along with the associated fear of widespread and unchecked 
dissemination of the credit card numbers. These same users may also be leery of conducting 
non-Internet related sales transactions using credit cards. One worry is that After all, anyone 
can steal a credit card number and use it later for unauthorized purchases. 

There are many applications where authentication may be useful, for example, 

20 opening a door to a secured location, buying commodities, entrance (and staying in ) a secret 
facility, e-commerce, and logging in to a system. Sometimes presenting an identification 
card, such as credit or social security, is adequate for authenticating a person, and sometimes 
the authentication requirements are so high that the authentication process requires biometric 
analysis. 

25 Currently, credit cards are used for authentication. They comprise a magnetic stripe 

that comprises the ID of the owner of the credit card and some additional details. Of course a 
conventional credit card provides relatively poor authentication, since its magnetic strip can 
be copied and an associated secret password (e.g., PIN) stolen rather easily. Today, in order 
to overcome this drawback, merchants usually verify the identity of the credit card holder 

30 with another identification means; e.g. an identification card or driving license. However, in 
remote authentication, such as purchasing commodities through the Internet or telephonic 
means, the merchant has no contact with the credit card or the cardholder itself. 
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There are two principal techniques currently used to handle a transaction where a 
credit card is involved. The first one is used for transactions of a "card present transaction" 
type, and the other is used for transactions of a ''non-present card transaction" type. 
According to the first technique, three key elements exist in the transaction. The first one is 
5 called "something you have"; namely the credit card. The second one is "something you 
know"; namely a password and the third element is <c having a witness"; namely the 
merchant's presence. These elements exist whenever a buyer is actually where the 
transaction is about to take place; e.g. in a shop. In this case the card's details are compared 
with the card's details contained in the card's issuer database. Verifying the cardholder is 

10 carried out by comparing his signature to the one on the card and/or using some sort of 
identifying card; e.g. a driving license. Since the card issuer confirms the card details and the 
transaction itself, the card issuer bears the consequences in case of a fraud However, in case 
of telephonic or Internet transactions, none of the above-mentioned elements exist and the 
merchant bears responsibility in case of a fraud. Solving the problem of "non-present card" 

15 transactions greatly reduces the risk taken by merchants and makes them more amenable to 
such transactions. 

Conventional business models, according to which credit card companies operate, 
pose a basic problem. The problem arises from the fact, that in a case of a "non-present card" 
transaction, there are generally two unsecured and parallel channels, which contribute to the 

20 risk of fraud. The first channel relates is the transaction channel itself. Whenever a 
cardholder wishes to carry out a transaction, he is asked by the merchant to give him details 
regarding the card and also his ID number. The merchant forwards these details to the card 
issuer (usually by phone) and upon approval of the transaction by the card issuer, the 
transaction is given a special code. The second channel is the authentication phase of the 

25 card by conventional methods, such as giving a password to the card issuer or by using a 
conventional electronic device. The problem in such cases is that the card issuer can not be 
sure that the specific code given to the transaction relates to the corresponding authenticated 
card. 

Currently, each merchant is likely to have a unique digital signature, and therefore it 
30 is relatively easy to secure the merchant side/domain. Additionally there are several solutions 
provided by several companies, such as CYOTA and ORBISCOM, according to which 
whenever a potential buyer wishes to make a transaction, a one-time credit card number is 
created by the merchant/seller. This kind of solution apparently reduces the risk of stealing a 
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credit card number. However, this is only a partial solution since this 'one-time' number is 
created and forwarded from the merchant to the card issuer, and the card issuer has to trust 
the merchant. 

A recent development in this field is the "Smart card". A smart card includes a built-in 
5 microprocessor and memory used for identification and/or financial transactions. A smart 
card is currently used in conjunction with a special electronic reading device. When such a 
card is inserted into a reader, it transfers data to and, and receives from, a central computer. It 
is more secure than a conventional magnetic strip card and can be programmed to lock if the 
wrong password is entered too many times. 
10 Generally, a conventional authentication system that involves a smart card comprises 

the following elements: 

- A card (may be called also "authentication token"), which comprises at least the ID of the 
card and a secret code, which is usually unique for each card; and 

- An authentication server, which comprises the details of each of the cards, their owner 
1 5 and their secret code. 

The authentication process in this case is carried out as follows: 

- Reading at least the ID of the card and the secret code from the smart card through an 
input device; 

- Transmitting the read data to the authentication server; 

20 - At the authentication server, comparing the read secret code with the one stored in the 
authentication at the ID's record, in order to find a match between the read secret code 
and the stored one, and 

- Sending a transmission with the result of the authentication to the initiator of the 
authentication. 

25 . The above mentioned conventional authentication scheme has some drawbacks: 

- Fraud of the card. Since the card is a digital / electronic device, it is vulnerable to fraud; 

- Fraud of the transmissions, especially when the transmissions are carried out via the 
Internet; and 

- Fraud of the details of the cards at the authentication center, especially by an in-house 
30 factor (such as an employee). 

One of the methods to increase the security level of conventional authentication 
schemes based on smart cards is the "one-time code". The one-time code mechanism usually 
generates pseudo-random numbers, which from an outsider point of view, are random 
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numbers. However, in some conventional systems the numbers can be predicted and 
abusively utilized, since the smart card and the authentication servers use the same numbers' 
generator. 

SUMMARY OF THE INVENTION 

5 An aspect of some embodiments of the invention relates to controlling an 

authentication process, for example, so as to protect a card merchant and/or a card user from 
fraud. In an exemplary embodiment of the invention, the protection comprises encrypting 
transmissions to a remote authentication server, for example to prevent tampering. 
Optionally, the encryption comprises signing with merchant related information, for 
10 example, so the authentication process can be reliably linked to both a card and a merchant. 
Alternatively or additionally, the encryption comprises signing the transmission at the user, 
for example to include user related and merchant page related information or a timestamp. 
Optionally, the merchant signature is provided by the authentication server or an associated 
entity* 

15 In an exemplary embodiment of the invention, the encryption is provided by software 

embedded or otherwise linked to a WWW page used by the user to access the merchant. 
Optionally, the embedded software will work only if the merchant is online and responding 
correctly. 

Alternatively or additionally, the merchant sends a one time code to the user, for 
20 each session and expects the code, hash thereof and/or a signed form thereof to be returned 

by the user. Thus, the user can be verified by the merchant. The code may be provided, for 

example using the embedded software. 

Alternatively or additionally, protection is provided by generating codes for an 

authentication card and then destroying initial numbers used to generate the codes. 
25 Alternatively or additionally, the codes used by a card are pre-set at the time a card is 

manufactured and no new codes are generated nor is there a way to generate them once the 

initial numbers are destroyed. 

Alternatively or additionally, protection is provided by the authentication server 

generating a simple authentication answer, without a reason. 
30 Alternatively or additionally, the history of authentication of a particular card is used 

to assist authentication. For example, a more restrictive authentication method is used for 

initial authentication, but if a consecutive authentication attempt is made with similar 

parameters (e.g., but with a counter that is increased by one or a small number), it may 
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succeed. Alternatively or additionally, the number of codes skipped between authentication 
attempts is used as an indication of the validity of an attempt. 

In an exemplary embodiment of the invention, various decisions may be made 
according to the results of the Authentication process, for example, if to freeze a card, allow 
5 a second attempt, warn a merchant and/or freeze a merchant (e.g., if many authentication 
errors come with a same merchant designation). 

An aspect of some embodiments of the invention relates to a method of signal 
detection for acoustic signals. In an exemplary embodiment of the invention, the method 
employs a tradeoff which allows less processing to be used, while allowing some types of 
10 errors. In an exemplary embodiment of the invention, the method comprises correlating 
Hilbert transforms of expected FSK frequencies, rather than correlating the frequencies 
themselves. This may allow various delays in an input signal to be correct for. 

In an exemplary embodiment of the invention, a sinusoidal signal is represented as an 
analytic signal using a Hilbert transform. It is then correlated with itself and integrated over 
15 an interval. The total power and/or other property of this integral is indicative of whether a 
signal is present or noise. 

There is thus provided in accordance with an exemplary embodiment of the 
invention, a method of authenticating, using an authentication server, the use of an 
authentication device over a communication network via an intermediate communication 
20 device, comprising: 

receiving an authentication datagram by said intermediate device; 
protecting said datagram by said intermediate device, by at least one of changing, 
adding to, encrypting and signing of said datagram; and 

forwarding said datagram to said authentication server for authentication. Optionally, 
25 said intermediate device comprises a vendor WWW site. Optionally, protecting comprises 
adding a signature associated with said vendor to said datagram. Optionally, protecting 
comprises encrypting said datagram. 

In an exemplary embodiment of the invention, said intermediate device comprises a 
user computing device. Optionally, said computing device adds a time stamp to said 
30 datagram. Optionally, said computing device adds a vendor-associated information item to 
said datagram. 
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In an exemplary embodiment of the invention, said computing device encrypts said 
datagram. Optionally, said encryption uses a one time code. Alternatively or additionally, 
said one time code is provided by a vendor for a particular session with said user. 

In an exemplary embodiment of the invention, said user computing device uses an 
5 embedded software component for said protecting. Optionally, said embedded software 
comprises an ActiveX component. Alternatively or additionally, said component is cached 
on said user device. Alternatively or additionally, said component requires a property value 
provided by a vendor to operate. 

In an exemplary embodiment of the invention, communication between said 
10 intermediate device and said server uses a secure connection. 

Alternatively or additionally, different communication paths are used for said 
authentication and for transaction details from said user. Alternatively or additionally, 
different communication paths are used for said authentication and for transaction details 
from a vendor to said authentication server. 
15 There is also provided in accordance with an exemplary embodiment of the 

invention, a method of authentication of an authentication datagram by a remote 
authentication server, comprising: 

sending an encrypted datagram by secure computer communication from a vendor 
software to said remote authenticate; 
20 comparing said datagram or a hash thereof to a hash table at said server, and 

generating a binary validation answer by said server without an associated 
explanation. 

There is also provided in accordance with an exemplary embodiment of the 
invention, a method of authentication of an authentication datagram by a remote 
25 authentication server, comprising: 

sending an encrypted datagram by computer communication from an authentication 
device to said remote authentication server, 

searching, at said server, for a hash value matching said datagram or a hash thereof; 

and 

30 generating a validation answer by said remote authentication server, responsive to 

said search, 
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wherein, said datagram includes a secret code and wherein said secret code exists 
only on said authentication device. Optionally, said authentication device includes a plurality 
of secret codes that are generated to appear unrelated. 

There is also provided in accordance with an exemplary embodiment of the 
5 invention, a method of generating a code set for an authentication device, comprising: 
providing a code generating software; 
providing at least one seed code for said software; 
generating said code set using said software and said seed; 
destroying said seed immediately after generating said code set; and 
10 storing said code set or an indication thereof on an authentication device. Optionally, 

the method comprises generating hash values for said code set. Optionally, the method 
comprises generating a second set of hash values for said code set, using a different hash 
function for said second set. 

There is also provided in accordance with an exemplary embodiment of the 
15 invention, a method of communication between a vendor and a user using an authentication 
device, comprising: 

generating a one time code for the user for a session; 
receiving an authentication datagram from said user; and 

passing on said datagram for verification by a remote authentication server if at least 
20 an indication of said one time code that matches said user is provided with said datagram. 
Optionally, the method comprises signing said datagram using said one time code by said 
user. 

There is also provided in accordance with an exemplary embodiment of the 
invention, a method of remote validation, comprising: 
25 receiving an authentication datagram by an authentication server from a remote 

authentication device; 

matching said datagram or a hash of said datagram to a table; 
calculating a counter value from a matching position in said table; and 
validating said authentication datagram based on an increase in said counter over a 
30 .previous counter being within a certain limit. Optionally, the method comprises: 
failing said authentication based on said increase being too large; and 
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allowing a subsequent authentication based on a further increase of said subsequent 
validation being below a second threshold. Optionally, said thresholds are the same. 
Alternatively, said second threshold is smaller than said certain threshold. 

In an exemplary embodiment of the invention, said counter comprises an ordinal 
5 position in said table that is not apparently related to a series of generated random numbers. 

There is also provided in accordance with an exemplary embodiment of the 
invention, a method of detecting a transmission of an acoustic multitone FSK signal, 
comprising: 

receiving an acoustic signal; 
10 converting the signal into a Hilbert-transform representation of the signal 

correlating said converted signal with at least one reference signal representing at 
least one expected frequency in said FSK signal; 

integrating said correlation over an interval; and 

determining if a signal is present, based on a thresholding of a result of said 
15 integrating. Optionally, the method comprises further determining if a detected signal has a 
frequency within a certain frequency range. Alternatively or additionally, the method 
comprises further determining if a detected signal has a signal to noise ratio within a certain 
signal to noise ratio range. 

In an exemplary embodiment of the invention, the method comprises resampling said 
20 signal after said determining. 

In an exemplary embodiment of the invention, said threshold is noise dependent of 
the received signal. 

In an exemplary embodiment of the invention, the method comprises calculating said 
interval based on a hardware characteristic of a producer of said acoustic signal. 
25 BRIEF DESCRIPTION OF THE DRAWINGS 

Non-limiting embodiments of the invention will be described with reference to the 
following description of exemplary embodiments, in conjunction with the figures. The 
figures are generally not shown to scale and any measurements are only meant to be 
exemplary and not necessarily limiting. In the figures, identical structures, elements or parts 
30 which appear in more than one figure are preferably labeled with a same or similar number in 
all the figures in which they appear, in which: 

Fig. 1 schematically illustrates a process for detecting existence of forged devices, 
according to one embodiment of the invention; 
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Fig. 2 schematically illustrates an authentication scheme of a device, according to an 
exemplary embodiment of the invention; 

Fig. 3 schematically illustrates using an ActiveX control to secure Internet 
transaction, according to a preferred embodiment of the invention; 
5 Fig. 4A is a flow-chart of an authentication process, according to one embodiment of 

the invention; 

Fig. 4B is a flow-chart of an authentication process, according to another 
embodiment of the invention; 

Fig. 5A schematically illustrates the structure of a multitone FSK signal according to 
10 an exemplary embodiment of the invention; 

Fig. 5B schematically illustrates a detector for a multitone FSK signal, according to 
an exemplary embodiment of the invention; 

Fig. 6 is a flow chart illustrating the process of detection and estimation of multitone 
FSK signal, in accordance with an exemplary embodiment of the invention; and 
15 Fig. 7 schematically illustrates a method for decoding a multitone FSK signal, in 

accordance with an exemplary embodiment of the invention. 

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 
Exemplary Implementation 

An example of an identifying device is a self-powered electronic card (SPC) that 
20 performs wireless communication with a standard PC or telephone without using a card 
reader. The card transmits a user identification code to a PC, a mobile, or a regular phone, 
enabling online authentication and physical presence in online transactions, Of course, non- 
card devices, such as statues and pens, may be provided as well. The authentication system 
may be designed to be implemented on various computer or telephony networks, such as the 
25 Internet, extranets, and IVR systems. 

Various cards and card related software and hardware which may be useful for 
carrying out and/or using the invention are described, for ©cample in 60/278,010, filed 
March 22, 2001, 09/853,017, filed May 10, 2001, 60/278,065, filed March 22, 2001, 
60/277,996, filed March 22, 2001, US patent application filed May 12, 2000, attorney docket 
30 20257-11, by applicants Alon Atsmon, et aL, and entitled 'Thysical Presence digital 
Authentication System", PCT/EL99/00506 filed on 16-Sep-99, PCT/IL99/00525 filed on 04- 
Oct-99, PCT/DL99/00521 filed on Ol-Oct-99, PCT/IB99/02110, filed on 16-Nov-99, 
PCT/IL01/00758 filed on 14-Aug-01, 09/820,358 filed March 28, 2001, PCT/EL98/00450 
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filed on 16-Sep-98 and a PCT application filed on even date by applicant Comsense, et aL 
and having attorney docket 100/02659, the disclosures of which are incorporated herein by 
reference. 

The card may also support payment card legacy systems, such as magnetic stripe 
5 readers. It can be implemented, for example as a standard credit card or a bankcard, a 
membership card, or a gift certificate, and works both on the Internet and in the offline 
world. Additionally, a conventional smart card's electronic circuit (e.g. an electronic 
microchip) may be embedded in the SPC. 

To use the card, in some embodiments of the invention, the cardholder squeezes a 
10 button provided on the card, while holding the card relatively close (e.g., approximately 3 
inches from) to the front of the PCs microphone. The card then sends a sonic transmission of 
a unique, one-time code to the device's microphone. 

In addition, a client software, which may be for example a communications layer 
embedded in a web page, receives this encrypted one-time code. The communication layer 
15 relays the code, unaltered (or as described below, for example, encoded and/or with data 
added), to a remotely located Authentication server for authentication. Current versions of 
the client software are generic database program based software, which are based on, but not 
limited to, Microsoft SQL and Oracle, for example. 

Thus, the card, in some embodiments of the invention, converts PCs or telephones 
20 into point of sale terminals, enabling secure Internet shopping, banking, and financial 
account services. 

The user software may be configured to receive the signal of an activated ComDot 
card (e.g., a card as described herein), launch a web browser and visit a specific URL, such 
as that of the card issuer. 

25 The card may serve as a user authentication, loyalty and secure transaction system, 

based around a credit card sized layer of electronic circuitry. This circuitry may be powered 
by an on-card battery, and activated by a flat switch, embedded in a standard credit card. 

After visiting the Web site of the manufacturer of the card, a communication layer 
(embedded in the Web site for example as an ActiveX control or JNI plug-in) may be cached 

30 into the user's browser. Upon card activation, the communication layer receives the signal 
from the card and authenticates the card through communication with a server running 
authentication software. The information transmitted by the card is received by a client 
software application, running on a Windows-compatible PC, or as part of a PC-based 
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telephony Interactive Voice Response (IVR) or Computer-Telephony (CTT) system. Other 
communication methods may be provided instead 

Optionally, upon verifying that a complete signal was received, the client software 
application sends the received signal- via a secure HTTPs or SSL network link- to the 
5 Authentication Server. In some embodiments of the invention, no decryption of the 
transmitted signal is performed on the client. It should be noted that encryption by the client 
is a separate step from using an SSL link, as it is performed by different software units, over 
which different degrees of control are available and different degrees and types of attacks by 
a hacker (or other malicious person) may be perpetrated. 
10 For remote authentication, the card's signal is optionally sent to the authentication 

server for example by the client software or an ActiveX control. The server software analyses 
this signal, then reports to the card issuer's or third party's web server as to whether the signal 
in question comes from a Valid (i.e. active card) or Invalid source. 

In an exemplary embodiment of the invention, the authentication system employs 
15 unique, one-time cryptographic codes for enhanced security. This one-time code is generated 
and encrypted by the card, and remains encrypted until it reaches the authentication server 
software. Optionally, no decryption of the data, which is received from the card, is performed 
in the authentication server. 

In an exemplary embodiment of the invention, when an e-wallet, merchant payment 
20 Web site or gateway, or other payment middle ware is equipped with a software client, the 
card authenticates cardholders to their payment card issuers and e-merchants, potentially 
reducing the problem of on-line fraud. Because the presence of a card in transactions can be 
proven (to some extent), cardholders shop online without fear of credit card theft. 

In some embodiments of the invention, additional protection steps may be taken. For 
25 example, using a random generator with three keys with values unique to each device, using 
a CRC for validating that transferred information have not been changed and/or different 
encryption functions and pseudo-random numbers for each card. 

In an exemplary embodiment of the invention, a Datagram structure used by the card 
may be as follows: 
30 - Header (not encoded) 

- Public ID (not encoded) 

- Private (secured) ID + Counter value (Encrypted by DES3) 

14 
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- ED AC (Error Detection And Correction code/information) 
Authentication of cards on the Internet: 

In an exemplary embodiment of the invention, a card is authenticated on the Internet 
using the following process: 

1 . The user activates the card by pressing the built-in button. 

2. The card takes a counter value stored on internal, non-erasable memory and uses it as a 
seed value that is DES3 encrypted. Then it transmits an acoustic signal carrying an 
encrypted message (e.g., the counter, a card ID, a time stamp and/or a transaction detail). 

3. The PC's software receives the signal and uses the contained ED AC packets to ensure 
that the message is viable and has not been interrupted, and to correct errors if any. If the 
message is verified, the PC strips off the EDAC and sends the message to the 
authentication server without it being decrypted by the PC. The authentication system is 
optionally designed to work with a secure clientrserver communications link such as 
HTTPs or SSL. In some embodiments, the message is first transmitted to a client site, 
for example a vendor site, where it is optionally not decrypted either before having 
information optionally added, optional encryption applied and being transmitted to an 
authentication server. 

4. The Authentication Server Software receives the message and performs a hash function 
on it. The output of this hash function is compared to a database of hash values 
maintained for each card. In an exemplary embodiment of the invention, only hash codes 
for the specified card are searched in the database. This feature is possible since the card 
ID number is also transmitted from the card to the Authentication server, thus allowing 
the server to limit the search process to a portion of the database, which corresponds to 
the specific card from which the transmission was received. If the hash function output 
of the received message appears in the database, the Authentication server reports to the 
card issuer's web server that the activated card is 'Valid'. If the hash output of the 
received card message does not appear in the database, or has been used in previous card 
activation, then the server reports that the activated card is 'Invalid'. The hash function 
employed is optionally a one-way function that cannot be reversed to find the initial data 
input. At no point is this data decrypted, and all the hashed data is optionally stored on a 
read media, potentially preventing accidental changes to this data. 

Authentication of the Telephony Cards: 
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In an exemplary embodiment of the invention, a card is authenticated on the 
telephone using the following process: 

1. A cardholder dials an enabled telephony service. An Interactive Voice Response and/or 
Computer-Telephony system answers the call, and the cardholder is prompted to activate 
5 his card. The client application (in this case the IVR and/or CTI application) receives the 
card transmission, and optionally forwards it to the Authentication Server (or a vendor 
site), where card authentication is optionally performed. At the server, telephony card 
authentication is optionally performed using a hash function process similar to that of the 
Internet cards. 

10 2. The authentication server's Valid or Invalid' indication is forwarded to the IVR and/or 
CTI system, which can, for example, admits cardholders to its telephony system, or 
requests card re-activation, according to its login policies. 
Communications Layer Software 

In an exemplary embodiment of the invention, two different implementations of the 
1 5 communications layer is provided, however, other implementations may be used as well: 

1. Tray Application: In this implementation, the communication layer is downloaded and 
installed by the user, typically in tandem with additional software provided by the card 
issuer (the communication layer could even be offered as a screen saver). Once 
installed, the communication layer runs in the background, waiting for a signal from the 

20 card. This persistently resident, "always on" implementation may be used, for example, 

for "electronic loyalty" applications, enabling one-click launch access to personalized 
web services. When triggered by the card, the persistently resident communication 
layer/tray application connect to the network, launch a browser, go to a specific URL, 
authenticate entry to the personalized service, and present the user with a personalized 

25 web service in a manner that is both convenient and secure. 

2. Active X Control - Web-page Embedded Version: In an exemplary embodiment of the 
invention, the communication layer's is implemented in a small size, which allows 
implementation in a Web page embeddable, for example, ActiveX or INI-plug-in 
format. Implementation in Active X, Netscape Plug-In, or in Java is useful for 

30 embedding the communication layer in web pages for automatic loading to users who 

visit the equipped Web site. 
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in this implementation, a first-time user would simply go to a particular card issuer 
web page in which the communication layer is embedded, and then activate the device. 
Possibly, no conscious user decision to download or install is required 
Authentication server 

5 The Authentication Server software can be implemented on a PC system running a 

Windows NT 4.0 or higher operating system, and Microsoft SQL server for Database 
software. 
ISO compatibility 

In an exemplary embodiment of the invention, the card will be ISO 7816 and ISO 
10 7810 credit card tested, for example, by Visa certified labs. These tests include torsion 
testing, involving 1,000 bends of the card. The tests also include exposure to heat, cold, 
water and acids. 
Card security 

In an exemplary embodiment of the invention, the card is secured physically and/or 
15 logically in order to prevent access to its secured data. 

Logical security is optionally achieved by encrypting the card's 'Secret User ID' and 
counter value using the DES3 encryption technique. The card's public ID is transmitted 
without encryption. 

Physically, the electronic circuit is optionally secured by its placement as the middle 
20 of five plastic layers. The two layers of plastic on either side of the electronics layer, and the 
card's lack of external connectors constitute a degree of physical security. Additionally, once 
the data is written to a card EPROM, the read and write fuses are burned, to prevent 
accessing the written information. 

2 unique. Triple PES fDES3 or T-DES) keys per device/card / 
25 In an exemplary embodiment of the invention, the encryption used in the card is 2 

key DES3 algorithm. Optionally, each card has two unique keys. These keys are randomly 
generated during the manufacturing process, for example, by a statistically safe, random 
generation mechanism. The keys are generated and written directly onto the card's non- 
erasable memory, and, as a security caution, are never stored outside of the card. In an 
30 exemplary embodiment of the invention, after using these 2-key DES3 and the hash function 
to generate the hash table, no trace of the two keys exists in the Authentication server. 
Optionally, the hash table is generated on the card and read off during manufacture. Then 
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various fuses on the card may be destroyed, for example physically, or by providing the card 
with a suitable command, for example, to erase the hash table. 

Optionally, the codes are prepared for particular customers, for example, so each 
customer can use his codes for validation. Optionally, the customer prepares the codes and 
5 only a hash is provided to the authentication server. The customer may then load the cards 
that he distributes, with the desired codes and/or hash values thereof. By providing the 
customer with a different hash value, the authorization server can allow the customer to 
perform his own validation, without compromising the validation at the authentication 
server. 

10 One-Time encrypted code 

In an exemplary embodiment of the invention, the card creates and encrypts a one- 
time code every time the card is activated. The encrypted data is, for example, 64 bits in 
length and contains, for example, two or more fields; the Secret card ID' and the Counter 
value. After each activation of the card the counter value is optionally incremented, making 

15 each transmitted code unique. Alternatively, a same one time code may be reused, for 
example, within 1 minute. 
EDAC 

In an exemplary embodiment of the invention, this information is transmitted not 
encrypted in order to verify that transmitted message is complete and to correct any error that 
20 may exist. 

Second factor authentication 

The clients may be advised to use a second factor of authentication in tandem with 
the first factor token authentication. The second factor may be, for example, a PIN/password, 
secret question, voice verification, or other preferred authentication methods. In an 
25 exemplary embodiment of the invention, the described method does not put limitations on 
the type of second factor authentication technique that can be employed. 
Server Software Security 
Comparison Function 

In an exemplary embodiment of the invention, the server authenticates a cardholder 
30 using a comparison function. The hashed version of the card's encrypted data bit stream is 
searched for in the hash database. Optionally, at no point is this data decrypted, and all the 
hashed data is a read only, preventing accidental changes to this data. The comparison 
function is used to compare the new counter click number (determined by the position in the 
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hash table that matches, for example) with the last known counter click number. Decisions 
are optionally made according to the result of this function. 
Limited External Communications 

In an exemplary embodiment of the invention, the server can send only two messages 
5 to the outside world: 'Card Valid' or 'Card Invalid', This feature potentially prevents hackers 
from knowing why the card was not validated by the server, information that is often 
important for improving attacks on the server. Li intra-network, secure communications with 
a card issuer or trusted third party server, the server optionally provides additional 
information as to why a particular card was not authenticated. In any case, when the card is 
1 0 retried, it may pass the authentication, for example by showing that the supposed card holder 
has at least two one time correct (and optionally consecutive) codes. 
Management 

In an exemplary embodiment of the invention, the system will enable administration 
. of various operations, which may be useful when issuing cards, for example described 
15 below. 

Card Issuance 

In an exemplary embodiment of the invention, a Card issuance process includes, in 
addition to the delivery of the cards to the users, one or more of the following operations: 
i. Addition of the card details to the database (e.g., basic record and/or hash list) 
20 ii. Association of the cardholder User ID and the Card ID (optionally performed during 
personalization) 

iii. Activating the card's functionality. This may involve sending an adequate command 
to the server (e.g., in case the default is off). Alternatively, automatic activation may 
be performed, for example if two consecutive correct hash values are provided. 
25 Card Revocation and Un-revocation 

In an exemplary embodiment of the invention, for card revocation and canceling of 
such a revocation, one or both of the following two mechanisms are optionally provided: 
i. A Web based management interface, which, after proper login, enables the 
operator/user to revoke cards based on the card JD[ 
30 ii. A Protocol based management interface, enabling a computer to automatically 
revoke cards using different protocols, as defined and agreed with a vendor and/or a 
user 
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Card Expiration 

In an exemplary embodiment of the invention, expired cards, assuming that new ones 
have been issued, will go through the revocation process, while in parallel, a new link will be 
created between the User ID and the new card. In addition to this process, the record of the 
5 cards and the hash list are optionally backed up (e.g., in case the backups are not in the same 
place). However, in an exemplary embodiment of the invention, no backing up is performed, 
as the hash list is generally static. 
Manufacturing 

Manufacturing is typically the first process in the card life span. 

10 In an exemplary embodiment of the invention, the card is assembled in one of the 

proprietary manufacturing lines, located within a Visa-certified facility. In an exemplary 
embodiment of the invention, a circuitry module is programmed with the manufacturer-Data, 
to be used later as the manufacturer-E) and Encrypted Data. The circuitry then goes through 
lamination and graphics, for example, cold lamination or hot lamination. The magnetic stripe 

1 5 (and/or Smart card module) is added, and the card is ready for personalization. Alternatively, 
the card may be personalized and/or various hash codes generated, prior to lamination. 
Authentication scheme : 

In an exemplary embodiment of the invention, according to the invention, one of two 
authentication schemes is used. According to a first scheme, a counter is embedded within 

20 the Self-Powered Card (SPC) and is used as a basis for generating a random number. The 
SPC also comprises a button, such that each time the button is pressed (i.e. the card is 
'clicked'), the counter's value increases, and a new random number is generated and 
transmitted to the authentication server along with the rest of the data. 

Upon receiving the SPC's data at the authentication server, a portion of the data is 

25 hashed. Since each SPC activation generates a new random number, a new hash number is 
generated at the server, to conform to the new counter's value. Knowing the rule by which 
the counter's value increases allows calculating the next future counter's values. In an 
exemplary embodiment of the invention, a set of, for example, 10,000 (or any other number) 
of pseudo-random numbers is calculated, and the resulting numbers are hashed and stored in 

30 a database contained in the Authentication server, for example prior to the first card use. In 
an exemplary embodiment of the invention, there is no need for the server to calculate, store 
or to use in any way, the original counter values. These values are only generated once in the 
card (i.e. when a card is 'clicked'; one new value/number for each click) for farther 
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generating the random numbers. In the Authentication server, each unique hash number 
reflects a specific card 'click' rather than the actual counter's value. Therefore, consecutive 
hash numbers in the server reflect consecutive card 'clicks' (i.e. activations). 

hi an exemplary embodiment of the invention, the Authentication process itself is 
5 carried out according to the following method: the server receives a random code data from 
the SPC. At least a portion of this data is hashed, and the resulting hash value is searched for 
in the server's database. If there is a matching number in the database, the corresponding 
SPC's 'click' number is compared against the last known 'click' number; i.e. the last time 
this SPC was authenticated. If the new 'click' number is equal or less than the last known 

10 'click' number, the SPC is considered to be invalid, hi this case the authentication server 
may hold any confirmation of transactions using this electronic card, or take any other action 
as/if required. A reasonable number of 'clicks* per time period may be allowed. For example, 
an average user may use the card for purchasing commodities, show the card to his friends, 
and click on the button unintentionally. For example, a card may be allowed no more than 

15 200 clicks per day. Hence, by keeping track of the click number and/or its history, 
unreasonable increments that may be an indication of a problematic SPC, can be detected or 
identified as artifacts. For example, a SPC user clicks his card, and the Authentication server 
interprets the received data as 'click number 12'. If, however, at the same day the server 
receives another data but interprets it as 'click number 220 s , the Authentication server 

20 'remembers' this click number (i.e. 220) and may decide to invalidate the card for this 
specific transaction. However, if later on the server receives from the same card a data that 
reflects a click number of 221, the card may be considered to be valid. Later on receiving 
click number 20, may be indicative of a real security problem. Optionally, the card (and 
server) uses a different set of hash numbers for each day. 

25 According to a second exemplary Authentication scheme, a set of random numbers is 

generated, hashed and stored both in the card and in the Authentication server. Optionally, no 
trace of the way by which this set of numbers is generated exists anywhere in the system after 
completing the numbers generation process. For example, the set may be generated by 
skipping some numbers in a series, for example, every other number, or using a random 

30 jump. 

In an exemplary embodiment of the invention, each time a card is 'clicked'; a pointer 
draws the next random number from the table, which is transmitted to the Authentication 
server. The server then searches for a matching hash number in its own table, in order to find 
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its corresponding click's number, after which it takes whatever required action, for example, 
using the same way as described in the first Authentication scheme. 

Optionally, the card ID number in the main table is used to reduce the searching time 
in the hash table. Alternatively or additionally, a reduction in search time is provided by 
5 removing used, old, and/or 'wasted', hash values from the hash table, a wasted hash number 
is a hash number that relates to (or is a representative of) false clicks; for example, whenever 
a card is clicked without its transmission being received at the Authentication server (e.g. 
accidental clicks). 

Security : One possible purpose of the security is to allow the owner of a device to carry out 
10 transactions in a secure manner, e.g., to ensure that the owner, and only the own©:, will issue 
a transaction. In an exemplary embodiment of the invention, achieving this object is provided 
by ofte or more of: 

(a) Prevention of exact duplicating of an electronic card; 

(b) Prevention of duplicating the operation logic of an electronic card; 

15 (c) Encrypting information being transferred between the electronic card and the 

authentication server; and 

(d) Storing encrypted information at the authentication server and a reference 
information at the electronic card. 

The authentication scheme described herein allows preventing a replay attack. 
20 However, replay attack is not the only security consideration. Optionally, one or both of the 
following issues is dealt with in accordance with an exemplary embodiment of the invention: 

(a) The integrity of the transferred information between the electronic card and the 
authentication server; and 

(b) Protection against untrustworthy employees at the authentication server's side; 
25 Security scheme based on ActiveX control : 

According to several embodiments of the invention, the device/card is used in 
Internet transactions. In an exemplary embodiment of the invention, there is a desire to 
prevent the risk of a hacker trying to pretend being a web merchant, by copying a merchant's 
web site, hi other words, a hacker may be able to 'get in the middle' between a legitimate 
30 user and a merchant, thus becoming an intermediate, or by pretending to be a real merchant 
and receive payment without providing goods. In such cases, the hacker may, for example, 
send the user a message, pretending to be a genuine merchant, urging/tempting the user to 
reply. A legitimate user would not be able to tell whether he responds to the genuine 
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merchant or to the hacker, and the hacker may take advantage of that fact by intercepting and 
abusively exploiting the data exchanged between the user and the genuine merchant. 

In an exemplary embodiment of the invention, in order to protect both cardholders 
and web merchants (and other ISPs), a special means is used in conjunction with an ActiveX 
5 control. The ActiveX control is a generic software element embedded in most of today's 
browsers. Whenever an Internet user enters a web site for the first time, the home page may 
prompt the user a request to download an ActiveX file, after which it remains in the user's 
PC. This file may at least contain parameters regarding the particular web page. If the user 
enters another web page, the user does not have to load the Active X again, and the already 
1 0 existing ActiveX dynamically changes its attributes to comply with the new web page. 

In an exemplary embodiment of the invention, a merchant must acquire at least one 
of two certificates in order to allow him to securely interact with other parties by using the 
Internet. These certificates may be issued, for example, by a Certification Authority (CA) or 
by the ASP itself. The first certificate is referred to as the 'client certificate'. This certificate 
15 is used by the Authentication Service Provider (ASP) to verify the merchant. The second 
certificate is referred to as the 'server certificate', and it is used to verify a legitimate Internet 
user. 

In an exemplary embodiment of the invention, whenever a card authentication is 
required, the card is activated so that a data stream is transmitted from the card and received 
20 at the user's PC. Assuming that the ActiveX is operable, it receives the transmission and 
modifies it according to the following process, at the user computer and/or at a merchant 
computer: 

1 . the ActiveX optionally adds the merchant's digital signature (i.e. the merchant 'server 
certificate') to the received data. This operation does not alter the original data 

25 received from the card; 

2. the ActiveX optionally, alternatively or additionally affiliates the specific web page 
parameters into the above signed data; 

3. the ActiveX optionally, alternatively or additionally encrypts the resulting data by 
using the merchant's public key; and 

30 4. the encrypted data is then forwarded from the merchant to the ASP. The ASP 
decrypts the data with its own private key, and the signed (by the merchant) data is 
extracted. The communication channel between the merchant and the ASP is secured, 
since it is carried out by using the SSL protocol and PKI technique. 
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Optionally, the ASP site (i.e. authentication server) has a list of all merchants' 
certificates and digital signatures, and stealing these two key elements; i.e. a digital signature 
and a certificate belonging to the same merchant, is necessary to execute a fraud. However, 
since it is almost impossible to steal these two elements, enhanced security may result. The 
5 data, which is transmitted from the card, is secured since the data from a legitimate user 
bears the ASP imprint, as is carried out by the ActiveX in the user's PC. A hacker may 
intercept a data sent from a legitimate user. However, the hacker cannot sign the intercepted 
data with the proper signature. Therefore, whenever the ASP receives a data transmission 
from a hacker, this data is most likely to have a false signature, and therefore is ignored. 

10 Alternatively or additionally, a special attribute is added to the ActiveX in such a 

way, that whenever a user makes an attempt to load an ActiveX control, the ActiveX control 
searches, while on runtime, for the special attribute. If such an attribute is not found, the 
ActiveX control will turn off automatically, otherwise the ActiveX control is ready to 
analyze incoming signals and take further actions as required. Possibly, the special attribute 

1 5 may be given by the Authentication Service Provider (ASP) to each authorized merchant. 

Alternatively or additionally, the following method is used, for example for 
increasing immunity to hackers. Each merchant assigns a special number to each user on a 
session basis; namely whenever a cardholder enters the merchant's web page, the merchant 
assigns the card user a random 'one-time' number. Upon activating the card, the ActiveX 

20 control is activated and the special number is added to the card's data and launched to the 
merchant's web server, where it is compared with the original number sent by the merchant. 
If several users enter the same merchant's web page essentially at the same time, each one of 
them is given a different number, and if a user exits and reenters the web page, he is given a 
number that differs from the previous number he had. Sending one-time numbers, and 

25 receiving them as a feedback, may ensure to the merchant that the user is really who he says 
he is. The card may be signed by the ActiveX control using the merchants code and/or using 
the card. 

Authentication server databases: 

In an exemplary embodiment of the invention, one or more of the following 
30 databases are provided for authentication, for example, at the server: 

1. MAIN TABLE - as is explained elsewhere in the text, while carrying out the 
manufacturing phase of the card, a set of for example 10,000 hashed codes is generated, 
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each code representing the futuristic data to be transmitted from a specific card. The 
whole set of hash codes/numbers is stored in this table. The main fields of the table are: 

1.1 HASH CODES - this field holds the generated 10,000 (or more, or less) hash codes. 
Every time a card is pressed, its 'one-time' code is received in the Authentication 
server, and its hashed result is searched for in this table. 

1.2 PUBLIC CARD ID - this optional filed stores a card's ID (or alternatively a 
registration number) that is received from the card un-encrypted. It should be noted 
that there may be a situation, where the number of issued cards is relatively large, in 
which case two cards may transmit exactly the same transmission. However, it is 
expected that the card IDs will remain unique. Additionally or alternatively, this ID 
number may be used to minimize the time required to find a hash code/number in 
this table. 

1.3 COUNTER VALUE - this optional field holds the expected future counter click's 
number of a specific card, in order to allow comparing between two consecutive data 
received from the card. 

2. CARDJDX TABLE - this optional table has one or more rows for each card. The main 
fields of the table are: 

2.1 CARD ID - this optional field represents the card's unique ID or registration 
number in the system. 

2.2 TIME - this optional field contains the timestamp of the last Authentication attempt. 

2.3 STATISTICS - this optional field holds the number of Authentication attempts and 
the number of failures and/or other statistics. 

2.4 LAST COUNTER VALUE - this optional field holds the last counter value for 
which the Authentication succeeded. 

2.5 LAST RESULT - this optional field holds an error code of the last Authentication 
attempt, or zero if the last Authentication was successful. 

2.6 STATUS - this optional field contains the status of the card, for example: 

• "O.K."; 

• "Expired"; 

• "Not initialized"; and 

• "Temporarily Locked" - this state may be initiated after a succession of 
erroneous Authentication attempts within a given period of time. 
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3. USER TABLE - this optional table contains one or more rows for each card issuer 
(which may or may not be the same as vendors). The main fields of the table are: 

3 . 1 CARD ID - this optional field is as above. 

3.2 USER ID - this optional field contains a user ID, such as a credit card number. 

5 3.3 Private Identification Number (PIN) VALUE - this optional field appears in clear 
text or in hashed form. This number is not necessarily included in the card and 
therefore may have no role in the above Authentication procedure. This number is 
similar to a hardware/device serial number. 
3.4 User Defined Fields (UDF) - these optional fields (for example 10 fields but other 
10 numbers are possible too) are reserved for each card user/issuer, which may decide 

to fill them with various data, such as card's holder bank account number, address, 
telephone number, allowed credit, etc. Each field may contain, for example a 
maximum of 64 characters. 

4. LOG TABLE - this optional table lists every Authentication attempt (or some - e.g., only 
15 failures and the last success). Every Authentication attempt adds a new record to this 

table, no matter what card's issuer or cardholder is involved. Some possible fields for 
this table are: 

4. 1 ID - optional, a number identifying the log entry. 

4.2 TIME - optional, the time stamp of each Authentication attempt. 

20 4.3 CARD ID - optional, if the card ID is not found, a generic value is returned. 

4.4 COUNTER - optional, counter of card for which an Authentication attempt was 
performed. If such a counter is not found, a generic value is returned. 

4.5 RESULT - optional, this field contains the results of the Authentication attempts. 

4.6 USER NAME - optional, stored here if it was provided by the service provider. 

25 4.7 USER IP ADDRESS - optional, stored here if it was provided by the service 
provider. 

5. MANAGEMENT LOG TABLE - this optional table contains information about card 
management operations performed via Web-site management tools. Some possible fields 
for this table are: 

30 5. 1 ID - optional, number identifying the log entry. 

5.2 OP CODE - optional, operation code, such as "Suspend Card" "Change and Card 
Password". 
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5.3 OP VALUE - optional, the result of the operation (OP CODE). 

As was described herein, in an exemplary embodiment of the invention, whenever an 
Internet transaction is carried out, a card issuer can not be sure that the transaction code 
given by the merchant and the authenticated card relate to each other. Since a web site is 
5 involved, whether the merchant's or the card issuer's, the problem can is optionally solved 
by using a proper ActiveX file, which may include various parameters relating to the 
merchant and/or to the transaction and/or the user/buyer, such as PC's IP address, timestamp, 
amount of transaction, URL and/or signature. 

Li some embodiments of the invention, a same device/card may be used in various 
10 applications, by using the same encrypted data generated by the card. The right application is 
selected according to the hash function applied by the corresponding Authentication server. 
For example, lets assume that there is a 2- application card, whenever this card transmits its 
data to a specific Authentication server, this server applies its unique hash function to 
Authentication the card. Should the user transmit his card data to the second Authentication 
15 server, another hash function is applied, to generate a different hash number. The differing 
hash functions and/or other associated information may be added, for example, by the vendor 
or by a subsidiary authenticator which may use the ASP for providing some authentication 
services. 

Fig. 1 schematically illustrates a process for authenticating a SPC, according to one 
20 embodiment of the invention. A card 100 transmits a counter value 10 and a card-ID 20 over 
a connection 30, to an authentication server 200, where the card ED is used to lookup in a 
table 40. Optionally, connection 30 is encoded, for example using the cards one time code. 

Fig. 2 schematically illustrates an authentication scheme of a device, according to 
another preferred embodiment of the invention. In this embodiment, a further security is 
25 provided by employing a security ID (e.g., a key) 50, at the card, for example one which is a 
public key of authentication server 200. The data may be hashed, as described above and 
used to lookup in a hash table 40, for example according to card-ID. 

Fig. 3 schematically illustrates an authentication situation, wherein an authentication 
service provider 35 (ASP) authenticates a user 300:31 (i.e. potential buyer) before carrying 
30 out an Internet transaction with a merchant 36, in accordance with an exemplary embodiment 
of the invention. By using his PC 33, the user 300 enters the merchant's web page 36. 
Entering the merchant's web page 36 for the first time prompts the user to download a copy 
of the generic ActiveX control 37A to the user's PC 37B. If the cardholder wishes to carry 
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out a transaction, he presses his card 31, which in turn launches the card's encoded details to 
the PC 33 by transmission signal 32. In an exemplary embodiment of the invention, the 
ActiveX control on the PC 33 has the capability to identify the transmitted signal 32; e.g. by 
detecting its frequency, transmission duration, checksum bytes or any combination of these 
5 attributes. If the transmitted signal is considered to be valid, the ActiveX control optionally 
digitally signs the card's data with the merchant web server's certificate. The ActiveX 
control optionally adds, to the signed data, the specific web page parameters, and optionally 
encrypts the resulting data by using the ASP's public key (or a public key relating to the 
merchant, for further verification by the ASP). The encrypted signal 32' is then sent to the 

10 merchant's web server 36. The merchant optionally adds his public key 36A and forwards 
the data to the ASP 35 optionally using the Secure Sockets Layer (SSL) protocol, which is a 
protocol for managing the security of a message transmission on the Internet 

In an exemplary embodiment of the invention, the ASP owns the Authentication 
Server, which optionally performs one or both of two principal tasks, one of which is to 

15 verify the merchant, and the second is to authenticate the card itself. Verifying the merchant 
and the user is simultaneously carried out by the ASP by comparing the received merchants 
server's certificate to the ASP's list. If the ASP finds it in his list (or using a hash thereof 
compares it to a suitable list), it indicates that the merchant is really who he says he is (e.g., if 
the ASP himself gave the certificate to the merchant). On the other hand, since the merchant 

20 certificate was added to the user's data in the user's PC, it also indicates that the user is really 
who he says he his, and the card authentication may be carried out. 

In an exemplary embodiment of the invention, the ActiveX 37A has an important role 
in the above-mentioned process, since it collects details from one or both of the merchant 
web page 36 and the user's PC (33), and digitally signs it with a server 30 certificate 36B of 

25 the merchant (which was provided to him by the ASP). The ActiveX also encrypts this data 
by using the public key of the ASP. 

Fig. 4A illustrates an Authentication scheme, in accordance with an exemplary 
embodiment of the invention. When the card is manufactured, a pseudo-random numbers 
generator (RNG) generates at least the secret card's ID number 42, the initial counter value 

30 41 and a 2-key T-DES (43). The 2-key T-DES is used to generate a random number, from the 
latter two types of data, each time the card is activated (i.e. 'clicked'). The 2-key T-DES is 
optionally permanently stored inside the card. Another mechanism is optionally stored inside 
the card, of which purpose is to change the counter value 41 each time the card is clicked. 
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Since the public card ID 44 typically does not play any role in the Authentication process, it 
is added to the transmitted signal 46 after the generation of the random data ^(45). It 
should be noted that the 2-key T-DES is only an option to generate the random numbers in 
the card, and other pseudo-random generators may be used instead. 

5 Since each transmission 46 from the card yields a progressively higher counter value, 

a new data content 45 is generated, which is a reflection of the secret card ID 42 and the 
counter's value 41. Knowing the rule by which the counter's value changes, an arbitrary- 
sized set of future numbers can be anticipated. In an exemplary embodiment of the invention, 
the card is expected to withstand at least 10,000 squeezes/presses, a set of 10,000 random 

10 numbers is hashed and stored in a database 50 or 40 (which is optionally contained in the 
Authentication server). 

Optionally, whenever the card is clicked, the card's counter value increases according 
to the predefined rule. The increased counter's value 41 and the card's secret ID number 42 
are used to generate a random number by applying the card's internal two predefined keys 43 

15 (T-DES). The random number 45 is transmitted, along with the public card ID 44, to the 
Authentication server through a receiving means; e.g. a PC. 

Optionally, upon receiving the transmitted data 46 from the card, the Authentication 
server extracts the public card ID (47), and generates from the remaining data a hash 
number 48 and the hashed number is searched for in the hash database/table column 49 

20 of table 50. 

In an exemplary embodiment of the invention, the rows in the hash table are arranged 
according to the original counter values; namely the first row of the table contains the hashed 
number 50: yl which represents the initial counter's value, the second row represents the 
second counter's value and so on. 

25. Optionally, the Authentication procedure is based on the counter click number (see 

table: 50). If the card is clicked for the first time, its counter's value is expected to be the 
initial random value as was set during the manufacturing process o<f the card. Upon receiving 
the transmitted data 46 from the card, the Authentication server applies the hash function 48 
on this data to yield the first hash number yl (49 A). Since yl represents the original first 

30 counter value, it is expected to be found in the first row in table 50, which corresponds to 
counter click number 1 (see table: 50). If yl is not found in table 50 or is not found in a low 
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row number, which can be for example pre-defined or a property of the user, which may be 
for example learned by the system, the card is assumed to be illegitimate. 

When the Authentication server receives the second transmission 46 from the card, 
the server hashes 48 the data X t ('i' denotes the card's click number) to yield another hash 
5 value 48: y it after which it is searched for in table 50. It is taken into account that a 
cardholder might mistakenly squeeze his card several times between each two transactions, 
but nevertheless, there is still a logical limit to such accidental squeezes. A decision-making 
algorithm, relating to this logical limit, may take into account different considerations. 
Therefore, if the second received data yields a hash number like y8, which represents counter 

10 click number 8, it might be considered a viable transmission of a legitimate card, If, 
however, the second received data yields a hash value like yl55 (49B), the card, from which 
this data was transmitted, may be considered illegitimate, or other decisions may be taken. 

The Authentication procedure optionally relates, therefore, to the difference between 
two consecutive card transmissions as received in the Authentication server and represented 

15 by the counter click number. 

In an exemplary embodiment of the invention, the same Authentication procedure 
repeats itself every time the Authentication server receives a transmitted data. Each received 
data is hashed, searched for in the hash table and the corresponding counter click number is 
compared against the last known counter click number. 

20 Fig. 4B illustrates a second, alternative, possible Authentication scheme. When the 

card is manufactured, a set 52 of pseudo-random numbers is generated, for example, by 
using a key 51 and hashed. The hash numbers are stored both in the card and in the server 50. 
Alternatively, original numbers may be stored in one or both locations. The random numbers 
generator/key 51 may be any generator known in the art. After completing the process of 

25 generating, hashing and storing the hash numbers, the key is discarded. Whenever a card is 
clicked, pointer 49C points to the (new) consecutive hash number, which is to be transmitted 
from the card. In the server, each received hash number (yl, y2, etc.) is searched for in table 
50, and if it is found, the corresponding counter click number is determined. 

The Authentication process is continued the same way as in the first scheme; namely 

30 by comparing the counter clicks of consecutive receptions from a card. 

In some embodiments of the invention, information is transmitted from the 
authentication/identification device over the telephony system. The telephony system is 
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typically designed to deliver audio signals, and thus high frequencies are filtered, and 
" therefore transmission of ultrasonic signals is usually acceptable over the regular telephony 
system. Thus, a sonic signal is utilized in telephony implementations. A same card may be 
used to transmit simultaneously both sonic and ultrasonic signals. More particularly, in an 
5 exemplary embodiment of the invention, the information is transmitted utilizing Frequency 
Shift Keying of sonic signals (herein after will be referred to as multitone FSK). 

In multitone FSK n different data symbols are represented by n different frequencies 
(i.e., each symbol is assigned a predefined frequency), so that the decoding of such a 
transmission is carried out by modulating data symbols utilizing transmission of signals of 
10 predefined frequencies. According to an exemplary embodiment of the invention four 
frequencies F0, Fl, F2, and F3, are utilized for the multitone FSK signal. 

Fig. 5 A schematically illustrates the structure of the multitone FSK signal according 
to an exemplary embodiment of the invention. The transmission starts with a detection 
preamble comprising two frequencies F0=1/T0 and F1=1/T1 (e.g., pure sinusoids, however, 
15 other wave forms, for example pre-filtered, may be used instead). The first part of the 
detection preamble comprise a signal of frequency F0 over an interval of nO*Tb seconds, and 
the second part of the detection preamble comprise a signal of frequency Fl over an interval 
of nl*Tb, where nO and nl are integers and Tb is the duration in seconds of a symbol, called 
the symbol interval. The frequency sequence utilized for detection may be comprised from 
20 any number of predefined frequencies, for example, from the set of frequencies utilized for 
FSK encoding. The detection preamble is optionally followed by a synchronization sequence 
and then by the encoded data. Other orders and/or signal parts may be provided, for example, 
an error correction section. 

The process of signal detection and encoding is illustrated in Fig. 6, in a form of a 

25 flow chart. The Hilbert transform x » = F * i H (^) X ^ of the signal x » , received in 610, is 

utilized in 600 to obtain the complex analytical representation x " JX » of the received 

signal. The complex analytic representation X * + J x » is used because under this model, 
sinusoids, which are functions with time varying amplitudes, become complex exponentials 
of unit magnitude. Sinusoidal signals correlated with each other with an unknown delay can 
30 yield a zero output, even when the two are of the same frequency. This can be seen from the 
following 
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b i ( * b \ 

\cos{(Dt)vos{<m + 6)dt=- cos9 \dt + Jcos(2crf + Q)dt 
f 0X d = -nl2 t a = 0 > 6 = r ja nd ® = 2?r/r ,wehave 



For the complex analytic representation, however, we have 

J exp (^ y^, j expj^- j^t + 0 j)# = exp(- j*) J<* = r exp(- jO) 

So that this form of correlation detection is less vulnerable to the delay incurred between the 
con-elated windows 9 9 or the duration of the correlation a-b, while allowing other signals to 
be erroneously detected. However, in the sonic transmission situation, considering expected 
echoes and/or frequency dependent artifacts and delays with signal generating hardware, 

10 such a tradeoff may be desirable. In addition, the tradeoff may allow a less computationally 
intensive detection method to be used, so that the PC may be used as a detector, rather than a 
dedicated DSP. Such a tradeoff may also be desirable in other problematic situations, for 
example, detecting RF signals transmitted by such a handheld card and detecting ultrasonic 
signals transmitted by the card and received by a non-dedicated microphone. 

15 At 601, 602, 603, 604, and 605, the detection of a transmitted signal is performed, for 

example based on correlation tests as illustrated in Fig. 5B. The detection is, for example, 
based on the correlation of 601 obtained by the correlators 501 and 511. The correlation in 
601 is performed on the received signal and a delayed portion of the received signal for the 
purpose of detecting the sinusoids F0 and Fl in the detection preamble of the transmission. 

20 Alternatively, other detection methods are used. 

The correlator 501 correlates the samples received in the interval 

^-K 2 fc) /2 - r - / (Bank 0) with the samples received in the interval 
t-(n Q T b )£t£t -(n Q T b )/2 ^ aTllc ^ w kere t is a given moment in time. Similarly, the 
correlator 51 1 correlates the samples received in the interval 
25 t-{n Q T b )-{n^ b )l2<r< l t-{n Q T b ) 2 ^ ^ 5^1^ received in the interval 

t- (»o + n \) T b * r - 1 ~ ( n o T b) - ( n i T b) f2 (Bank 3). The choice of symbol interval Tb used in 
calculating the above correlations is optionally derived from considerations regarding the 
hardware that generates the transmission waveform. In accordance with the hardware, 
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minimum and maximum symbol durations * are optionally identified, from which the 
correlator will use the minimum. In this way, the correlators may be better guaranteed to 
exclusively identify their intended frequencies. 

In 602 the correlators results are validated, this is optionally performed utilizing 
5 slicers 502 and 512. The slicers 502 and 512 optionally issue a TRUE indication whenever 

the correlation result is greater that a predetermined threshold, 7,0 and ^ respectively. If the 
signal received is of the form depicted in Fig. 5 A, than the output of correlators 501 and 511 
will indicate a maximal correlation, and slicers 502 and 512 will issue a true indication, 
which will result in issuing a TRUE indication on 516 (i.e., signal detection). In an 

10 exemplary embodiment of the invention, the threshold is determined based on the noise 
level, for example, by analyzing the amplitude level in a known part of the signal for 
example, the preamble. 

Alternatively or additionally to the above correlation metric, the complex analytic 
signal may be used to estimate the frequency in the given windows (F0 and Fl). Assuming 

15 that the signal in the window is a complex exponential, then through the entire window, we 
can expect the waveform to look like 
r n =e Jm + $ +v n n = t-n t T b ,... 9 t 

where v « is noise. Accordingly, multiplying any sample r " by its delay conjugated r *+ will 
yield the constant 

20 r « r »-i 

Thus, by finding the angle of the complex number rnr ^ x and averaging over the 

window n^t-niTb*--'* 9 ^ estimate of the frequency ® may be found. Optionally, the 
estimate is compared with a bounds on what frequency are allowed, which bound is 
optionally defined based on the inherent inaccuracies in the hardware that generates the 
25 signal and/or well as the minimum SNR allowed. Therefore, a signal may be accepted based 
on whether it has sufficient correlation energy (from the correlators 501 and 511) and/or 
whether it has an acceptable frequency. 

On the other hand, if one of the correlation results, from 501 and 511, is not higher 

than the respective threshold (^° or ^ ), the correlation is invalid, and the process starts all 
30 over again from 610 as a new sample is retrieved. If the correlation passes the validation test 
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in 602, in 603, another test is optionally performed to determine whether the frequencies and 
the SNR (Signal to Noise Ratio) are within an acceptable tolerance for detection. The 
frequencies are optionally estimated using an approach described in "A Fast and Accurate 
Single Frequency Estimator." by Kay, SM, IEEE Transactions on Acoustics, Speech, and 
5 Signal Processing, Vol 37, No 12, Dec 1989, where the data used in the Kay analysis is the 
same as that already in the delay lines for using the correlator detector described previously, 
whereas the SNR is determined by using a window of delayed samples to estimate the 
frequency-dependent noise power. Once the noise power is estimated, detection is optionally 
determined using statistical hypothesis testing between the energy at the output of the 

10 received correlators and the energy at the same frequency, as estimated from the noise 
window. Ultimately, the threshold is optionally calculated using the Neyman-Pearson 
criterion. (This approach is described in US patent application No. US 09/570,399 of the 
same applicant). If it is determined that frequencies and the SNR are not acceptable for 
detection the process starts again from 610 (as a new sample is retrieved). 

15 After high resolution estimation of the transmitted frequencies is performed, 605, the 

frequencies obtained are optionally tested in 604, to determine whether they are in an 

acceptable range in view of the frequencies deviations. As before, if it is determined that the 

estimated frequencies are not in an acceptable range, the process starts again from 610 (as a 

new sample is retrieved). If the estimated frequencies are in range, in 606 resampling 

T k 
20 (interpolation) is performed so that the symbol interval b will be an integer multiple ' of 

the new sampling interval 5 , so that * * * . By forcing this relationship through 
interpolation, the data frequencies, which are all related to the symbol interval by the relation 

Ji T 

with C/ an integer, will generally be orthogonal to each other in the digital domain with 

25 samples spaced by * . In this way, when detection is performed, interference between 
symbols is optionally minimized. The resampled signal is then optionally utilized in 607 to 
calculate the signal's timing from a known preamble, (This approach is described in US 
patent application No. US 09/570,399 of the same applicant), which is utilized in 608 to 
further determine if the signal is valid If it is determined that the signal is invalid, the 

30 process starts again from 610 (as a new sample is retrieved). If a valid indication is obtained 

in 608, detection is completed and the decoding operations are performed in 609. Other 
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detection schemes, for example with fewer levels or with a greater number of levels and/or 
with additional and/or alternative verification criteria, may be used. 

•Fig. 7 schematically illustrates the decoding operation, according to a preferred 
embodiment of the invention. The resampled signal, obtained in 606, is correlated in 
5 correlators 701, 702, and 703. The number of correlators is optionally the same as the 
number of different frequencies (symbols) utilized for the FSK transmission. Alternatively, a 
single correlator may be reused. The resampled signal 700 is correlated with the estimated 

frequencies for each signal fi> o» fi) i»-» fi) » > which were estimated, for example, from the Kay 
algorithm referenced above. The slicers 711, 712, and 713, test the output of each correlator 

10 701, 702, and 703, respectively, to determine if a maximum correlation is obtained. 
Whenever the output of a correlator 701, 702 or 703, exceed the threshold of the 
corresponding slicer, a match indication is issued on the output of the respective slicer. This 
indication is actually a decoded symbol. 

It will be appreciated that the above-described methods of authentication may be 

15 varied in many ways, for example, changing the order of steps or the number of security 
mechanism used. While the application has focused on card authentication over the Internet, 
other authentication situations are intended as well. In addition, a multiplicity of various 
features, both of methods and of devices has been described. Where methods are described, 
devices for carrying out the methods are also contemplated. It should be appreciated that 

20 different features may be combined in different ways. In particular, not all the features shown 
above in a particular embodiment are necessary in every similar exemplary embodiment of 
the invention. Further, combinations of the above features are also considered to be within 
the scope of some exemplary embodiments of the invention. Also within the scope of the 
invention are software hardware and/or firmware for carrying out the methods, and devices 

25 and/or software for programming existing devices to make the device comply with the 
methods described herein. Section headings where they appear are meant for clarity of 
browsing only and should not be construed as limiting the contents of a section to that 
particular section. When used in the following claims, the terms "comprises", "includes", 
"have 11 and their conjugates mean "including but not limited to". 

30 It will be appreciated by a person skilled in the art that the present invention is not 

limited by what has thus far been described. Rather, the scope of the present invention is 
limited only by the following claims. 
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